compute: columnar Get/Mfp output via as_collection_core - #37763

Measured at this commit through as_collection_core, 400,000 single-int64 output rows. Unkeyed path (flat_map_datums, one session per input message): 391 messages of 1024 records, so the producer now passes the input message size through instead of re-cutting it to 204. Keyed path (PendingWork::do_work opens one session and walk_cursor pushes into it until REFUEL = 1,000,000 records, so FLUSH_THRESHOLD_WORDS at src/timely-util/src/columnar/consolidate.rs:62 is what bounds the message): 6 messages of ~67,400 records, against ~1,960 messages of 204 before, a 330x jump. A 1 KiB row still gives ~1,800 records per message, 9x. Message::push_at ships a container as one message and never splits it.

flat_map_stage pops one queue entry per input message, runs data.for_each_record(...) to completion (src/compute/src/render/flat_map.rs:170), and only then checks if budget == 0 (:187); neither process_flat_map_row nor drain_through_mfp breaks out of the per-record loop. The operator doc at :50 already states it "can only yield between input batches, but not from within a batch". The unkeyed FlatMap input consumes the edge directly (flat_map.rs:58-66), and message sizes propagate, since a downstream Mfp re-emits at whatever size its input arrived in. One arrangement-scan Get upstream therefore sets the granularity for the rest of the chain: a generate_series(1, 100) behind such an input goes from ~20k output records per activation to ~6.7M in one non-preemptible activation, stalling peeks and frontier advancement for every dataflow sharing that worker.

Two smaller consequences of the same size change: where the edge forks, Tee clones a ~1.8 MiB column per extra consumer rather than a 204-record Vec, and the ColumnarToVec seams (sink, LetRec binding, temporal bucketing) materialize a whole container's worth of owned Rows per activation.

The ~1.8 MiB ship threshold is ColumnBuilder's, and until this PR it was only ever reached on the arrange path (FormArrangementKey into mz_arrange_core), which is built for bulk; no producer emitted CollectionEdge::Columnar. This PR is what puts containers of that size on a general-purpose collection edge in front of arbitrary Pipeline consumers. The within-batch fuel gap in FlatMapStage is itself already tracked in Linear CPU-163; what this diff changes is the size of the batch. Bounding what this producer ships is the narrow fix; letting FlatMapBatch::for_each_record stop and resume at an offset is the durable one, and the Column arm is index-addressable so the resume state is one usize.